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Abstract 


This document describes two technology-independent extensions to 
Generalized Multi-Protocol Label Switching (GMPLS). The first 
extension defines the new switching type Data Channel Switching 
Capable. Data Channel Switching Capable interfaces are able to 
support switching of the whole digital channel presented on single 
channel interfaces. The second extension defines a new type of 
generalized label and updates related objects. The new label is 
called the Generalized Channel_Set Label and allows more than one 
data plane label to be controlled as part of a Label Switched Path 
(LSP). 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6002. 
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1. Introduction 


This document describes two technology-independent extensions to 
Generalized Multi-Protocol Label Switching (GMPLS). Both of these 
extensions were initially defined in the context of Ethernet 
services, see [RFC6004] and [RFC6005], but are generic in nature and 
may be useful to any switching technology controlled via GMPLS. 


The first extension defines a new switching type, which is called 


Data Channel Switching Capable (DCSC). DCSC interfaces are able to 
support switching of the whole digital channel presented on single 
channel interfaces. The second extension defines a new type of 
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generalized label and updates related objects. The new label is 
called the Generalized Channel_Set Label and allows more than one 
data plane label to be controlled as part of a GMPLS Label Switched 
Path (LSP). 


1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Data Channel Switching 


Current GMPLS switching types are defined in [RFC3945] and [RFC3471] 
and support switching at the packet (PSC), frame (L2SC), time-slot 
(TDM), frequency (LSC), and fiber (FSC) granularities. Parallel 
definitions for these switching types are also made in [RFC4202], 
[RFC4203], and [RFC5307]. 


One type of switching that is not well represented in this current 
set is switching that occurs when all data received on an ingress 
port is switched through a network to an egress port. While there 
are Similarities between this level of switching and the "opaque 
single wavelength" case, described in Section 3.5 of [RFC4202], such 
port-to-port switching is not limited to the optical switching 
technology implied by the LSC type. FSC is also similar, but it is 
restricted to fiber ports and also supports multiple data channels 
within a fiber port. 


This document defines a new switching type called Data Channel 
Switching Capable (DCSC). Port switching seems a more intuitive 
name, but this naming collides with PSC so is not used. DCSC 
interfaces are able to support switching of the whole digital channel 
presented on single channel interfaces. Interfaces that inherently 
support multiple channels, e.g., Wavelength Division Multiplexing 
(WDM) and channelized TDM interfaces, are specifically excluded from 
this type. Any interface that can be represented as a single digital 
channel are included. Examples include concatenated TDM and line- 
encoded interfaces. Framed interfaces may also be included when they 
support switching on an interface granularity, for example Ethernet 
terminated at the physical (port) level and all traffic received on a 
port is switched to a physical port at the LSP egress. 


DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the 
value 125. The DCSC value is carried in routing protocols in the 
Interface Switching Capability Descriptor defined in [RFC4202], and 
used in OSPF [RFC4203] and IS-IS [RFC5307]. These documents are not 
otherwise modified by this document. 
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The DCSC Switching Type may be used with the Generalized Label 
Request object, [RFC3473], or the Generalized Channel_Set 

LABEL REQUEST object defined below. Port labels, as defined in 
[RFC3471], SHOULD be used for LSPs signaled using the DCSC Switching 


Type. 


2.1. Compatibility 


Transit and egress nodes that do not support the DCSC Switching Type 
when receiving a Path message with a Label Request containing the 
DCSC Switching Type will behave in the same way nodes generally 
handle the case of an unsupported Switching Type. Specifically, per 
[RFC3473], such nodes are required to generate a PathErr message, 
with a "Routing problem/Unsupported Encoding" indication. 


Ingress nodes initiating a Path message containing a Label Request 
containing the DCSC Switching Type, receiving such a PathErr 
messages, then notify the requesting application user as appropriate. 


3. Generalized Channel_Set Label Related Formats 


This section defines a new type of generalized label and updates 
related objects. This section updates the label-related definitions 


of [RFC3473]. The ability to communicate more than one label as part 
of the same LSP was motivated by the support for the communication of 
one or more VLAN IDs. Simple concatenation of labels as is done in 


[RFC4606] was deemed impractical given the large number of VLAN IDs 
(up to 4096) that may need to be communicated. The formats defined 
in this section are not technology specific and may be useful for 
other switching technologies. The LABEL SET object defined in 
[RFC3473] serves as the foundation for the defined formats. 


3.1. Generalized Channel_Set LABEL REQUEST Object 


The Generalized Channel_Set LABEL REQUEST object is used to indicate 
that the Generalized Channel_Set LABEL object is to be used with the 
associated LSP. The format of the Generalized Channel_Set 
LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST 
object and uses a C-Type of 5. 


3.2. Generalized Channel_Set LABEL Object 


The Generalized Channel_Set LABEL Object communicates one or more 
labels, all of which can be used equivalently in the data path 


associated with a single LSP. The format of the Generalized 
Channel_Set LABEL Object is based on the LABEL _SET object defined in 
[RFC3473]. It differs from the LABEL SET object in that the full set 


may be represented in a single object rather than the multiple 
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objects required by the [RFC3473] LABEL SET object. The object MUST 
be used on LSPs that use the Generalized Channel_Set LABEL REQUEST 
object. The object MUST be processed per [RFC3473]. Make-before- 
break procedures, see [RFC3209], SHOULD be used when modifying the 
Channel_Set LABEL object. 


The format of the Generalized Channel_Set LABEL object is: 
o Generalized Channel_Set LABEL object: Class = 16, C-Type = 4 


0 a 2 3 
01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++H 

| Channel_Set Subobject 1 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-4+-4-4-4-4-4-4-4+-4+-4-4+-4-4-4+-4+-4-4+-4-4+-4+-4+-4+-4+-4+-4-4+-4-4-4-4-4-4 


| Channel_Set Subobject 


+-4+-4+-4-4-4-4-4-4+-4+-4-4-4-4-4+-4+-4+-4+-4-4-4-4+-4+-4-4-4-4-4-4-4-4-4-4 


at 


The Channel_Set Subobject size is measured in bytes and MUST always 
be a multiple of 4, and at least 4, and has the following format: 


0 1 2 3 

OF de 2 SA Bi Oe 28 GO 23 AB Oe EB OO A 23 AS, 6:1 BO. OL 
Pot rH Ht rtm t arta T ta tatarta ta totaota ta tataototatatototatatototat 
| Action | Num Subchannels | Label Type 
FoF H Hart mtr tartan tartar tartar E ta totrta ta tataototatatotaotatatototat 
| Subchannel 1 | 
| SAA a a a L ALAA 
| phs | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Subchannel | 
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| orara | Padding | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+2+ 
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Action: 8 bits 


See [RFC3471] for definition of actions. Range actions SHOULD be 
used when possible to minimize the size of the Channel_Set LABEL 
Object. 


Number of Subchannels: 10 bits 


Indicates the number of subchannels carried in the subobject. 

When the number of subchannels required exceeds the limit of the 
field, i.e., 1024, multiple Channel_Set Subobjects MUST be used. 
Note that the size of the subobject may result in a Path message 
being larger than a single unfragmented IP packet. See Section 
4.4 of [RFC6004] for an example of how this case may be handled. 


A value of zero (0) has special meaning and MAY be used in either 
the LABEL or UPSTREAM_LABEL object. A value of zero (0) is used 
in a LABEL or UPSTREAM_LABEL object to indicate that the 
subchannel(s) used in the corresponding (downstream or upstream) 
direction MUST match the subchannel(s) carried in the reverse 
directions label object. When value of zero (0) is used, no 
subchannels are included in the Channel_Set Subobject and only one 
Channel_Set Subobject may be present. The zero (0) value MUST NOT 
be used in both the LABEL and UPSTREAM_LABEL objects of the same 
LSP. Note that unacceptable label values continue to be handled 
according to [RFC3209] and [RFC3473], i.e., they result in PathErr 
or ResvErr messages with a "Routing problem/Unacceptable label 
value" indication. For example, in the case where a Resv message 
containing a zero (0) in both the LABEL and UPSTREAM_LABEL objects 
is received, the node would generate a ResvErr message. 


Label Type: 14 bits 
See [RFC3473] for a description of this field. 
Subchannel: Variable 


See [RFC3471] for a description of this field. Note that this 
field might not be 32-bit aligned. 


Padding: Variable 


Padding is used to ensure that the length of a Channel_Set 
Subobject meets the multiple of 4 byte size requirement stated 
above. The field is only required when the Subchannel field is 
not 32-bit aligned and the number of included Subchannel fields 
result in the Subobject not being 32-bit aligned. 
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The Padding field MUST be included when the number of bits 
represented in all the Subchannel fields included in a Generalized 
Channel_Set Subobject result in the Subobject not being 32-bit 
aligned. When present, the Padding field MUST have a length that 
results in the Subobject being 32-bit aligned. When present, the 
Padding field MUST be set to a zero (0) value on transmission and 
MUST be ignored on receipt. These bits SHOULD be passed through 
unmodified by transit nodes. 


Note that the overall length of a Channel_Set Subobject is 
determined based on the value of the Num Subchannels field 
together with the size of each Subchannel field as well as any 
required padding. The size of the Subchannel field is uniquely 
identified by the Label Type field. 


3.3. Other Label-Related Objects 


The previous section introduced a new LABEL object. As such the 
formats of the other label-related objects and subobjects are also 
impacted. Processing of these objects and subobjects is not modified 
and remains per their respective specifications. The other label 
related objects and subobjects are defined in [RFC3473] and include: 


— SUGGESTED_LABEL object 

- LABEL _SET object 

— ACCEPTABLE _ LABEL SET object 
— UPSTREAM LABEL object 

— RECOVERY_LABEL object 

— Label ERO subobject 

— Label RRO subobject 


The label-related objects and subobjects each contain a Label field, 
all of which may carry any label type. As any label type may be 
carried, the introduction of a new label type means that the new 
label type may be carried in the Label field of each of the label- 
related objects and subobjects. No new definition needs to specified 
as their original specification is label-type agnostic. 


3.4. Compatibility 


Transit and egress nodes that do not support the Generalized 
Channel_Set Label related formats will first receive a Path message 
containing Generalized Channel_Set LABEL REQUEST object. When such a 
node receives the Path message, per [RFC3209], it will send a PathErr 
with the error code "Unknown object C_Type". 
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Ingress nodes initiating a Path message containing a Generalized 
Channel_Set LABEL_REQUEST object on receiving such a PathErr 
messages, then notify the requesting application user as appropriate. 


4. IANA Considerations 


IANA has assigned new values for namespaces defined in this document 
and summarized in this section. The registries are available from 
http://www.iana.org. 


4.1. Data Channel Switching Type 


IANA has made the following assignment in the "Switching Types" 
section of the "GMPLS Signaling Parameters" registry. 


Value Type Reference 


125 Data Channel Switching Capable (DCSC) [RFC6002] 


The assigned value is reflected in IANAGmplsSwitchingTypeTC of the 
ITANA-GMPLS-TC-MIB available from http://www.iana.org. 


4.2. Generalized Channel_Set LABEL REQUEST Object 


IANA has made the following assignment in the "Class Names, Class 
Numbers, and Class Types" section of the "RSVP PARAMETERS" registry. 


A new class type for the existing LABEL_REQUEST Object class number 
(19) with the following definition: 


Class Types or C-Types: 
5 Generalized Channel_Set [RFC6002] 
4.3. Generalized Channel_Set LABEL Object 


IANA has made the following assignment in the "Class Names, Class 
Numbers, and Class Types" section of the "RSVP PARAMETERS" registry. 


A new class type for the existing RSVP_LABEL Object class number (16) 
with the following definition: 


Class Types or C-Types: 


4 Generalized Channel_Set [RFC6002] 
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5. Security Considerations 


This document introduces 
signaling [RFC3473]. It 
messages, nor change the 
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new message object formats for use in GMPLS 
does not introduce any new signaling 
relationship between LSRs that are adjacent 


in the control plane. As such, this document introduces no 


additional security cons 
security considerations. 


iderations. See [RFC3473] for relevant 
Additionally, the existing framework for 


MPLS and GMPLS security is documented in [RFC5920]. 
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